home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / Documents / CERT / cert_summaries / CS-95:01 < prev    next >
Encoding:
Text File  |  1996-02-16  |  8.1 KB  |  170 lines
  1. ---------------------------------------------------------------------------
  2. CERT Summary CS-95:01
  3. July 26, 1995
  4.  
  5. As part of our ongoing efforts to disseminate timely information about
  6. Internet security issues, the CERT Coordination Center is pleased to announce
  7. the CERT Summary.  CERT Summary will be distributed periodically to call
  8. attention to the types of attacks currently being reported to the CERT
  9. Coordination Center.  The summary will include pointers to sources of
  10. information for dealing with the problems.
  11.  
  12. ---------------------------------------------------------------------------
  13.  
  14. Recent Activity
  15.  
  16. The majority of incidents reported to the CERT Coordination Center in 
  17. recent weeks fall into three categories:
  18.  
  19. 1.  IP Spoofing:  We have seen a surge in IP spoofing.  In recent weeks, we
  20.     have received more than 170 reports of IP spoofing attacks or probes, many
  21.     of them resulting in a successful break in.  Several sites believed
  22.     incorrectly that they were blocking such packets.  Others planned to block
  23.     them but hadn't yet done so. 
  24.  
  25.     We urge you to take the time to review CERT Advisory CA-95:01, "IP
  26.     Spoofing Attacks and Hijacked Terminal Connections," which has
  27.     details on this type of attack and how to prevent it. Vulnerability 
  28.     to IP spoofing attacks is NOT limited to any specific router or OS vendor.
  29.     This advisory is available from
  30.  
  31.           ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing
  32.           ftp://info.cert.org/pub/cert_advisories/CA-95:01.README
  33.  
  34. 2.  Packet Sniffers:  We receive new reports daily that describe sniffers
  35.     installed on compromised hosts.  These sniffers, which are used to collect
  36.     account names and passwords, are frequently installed using a kit.
  37.     Further information on packet sniffers is available from
  38.  
  39.   ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
  40.   ftp://info.cert.org/pub/cert_advisories/CA-94:01.README
  41.  
  42.     Once root is compromised on a system, the sniffer kit can be activated
  43.     to collect account names and passwords.  Note that even if sniffing
  44.     capabilities are disabled by recompiling and rebooting the kernel, we
  45.     have received reports of intruders re-enabling these capabilities by
  46.     recompiling and rebooting systems.  Pay particular attention to every
  47.     system reboot.
  48.  
  49.     In the attacks that we have seen, intruders frequently install (as root)
  50.     Trojan horse system software that is available with the sniffer kit.
  51.     Further information on the Trojan horses that we have seen is available
  52.     from
  53.  
  54.           ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums
  55.           ftp://info.cert.org/pub/cert_advisories/CA-94:05.README
  56.  
  57. 3.  NFS Attacks:  We have seen a large increase in the number of attacks
  58.     and probes against weaknesses within NFS. Again, many of these are
  59.     successful.  Programs to automate such attacks have become widespread.
  60.  
  61.     Please review CERT Advisory CA-94:15, "NFS Vulnerabilities," and its
  62.     associated README file. They are available from
  63.  
  64.           ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities
  65.           ftp://info.cert.org/pub/cert_advisories/CA-94:15.README
  66.  
  67.     A successful attack usually results in the intruders gaining root access.
  68.     Intruders have been targeting machines with vendor-licensed source code.
  69.     They appear to be in search of the code for system software with the view
  70.     to creating and installing copies containing Trojan horses on compromised
  71.     systems.  If you manage systems that contain vendor-licensed source code,
  72.     pay particular attention to the "Security Measures" section of the
  73.     advisory. 
  74.  
  75. -------------------------
  76. New Trojan Horse Programs
  77.     
  78.     Once root has been compromised on a system, we are finding new Trojan
  79.     horses installed in the inetd and in.rexecd daemons.  These Trojan horses
  80.     allow an intruder to gain access at a later time, bypassing most firewall
  81.     and TCP wrapper configurations.  Do not rely on checksums determined by
  82.     the sum(1) program because intruders are creating files whose
  83.     checksums match those of the vendor-distributed versions.  Do not rely
  84.     on time stamps of these files either because intruders are setting
  85.     these to previous values as well.
  86.  
  87.     We recommend that you use a known clean version of cmp(1) to make a direct
  88.     comparison of the binaries and the appropriate distribution media.
  89.  
  90.     Alternatively, you can check the MD5 results on suspect binaries against
  91.     a list of MD5 checksums from known good binaries.  Ask your vendor to make
  92.     MD5 checksums available for their distribution binaries.  You can also
  93.     consult the following for some additional information on MD5:
  94.  
  95.           ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums
  96.       ftp://info.cert.org/pub/cert_advisories/CA-94:05.README
  97.  
  98.    In addition, tools such as Tripwire can archive MD5 checksums of known good
  99.    binaries when used immediately after a system installation.  If you use
  100.    Tripwire, you should regularly maintain the checksums on removable or
  101.    read-only media.  For more details on Tripwire and MD5, see the CERT
  102.    security checklist:
  103.  
  104.           ftp://info.cert.org/pub/tech_tips/security_info
  105.  
  106.     We are also seeing Trojan horses introduced into shared object libraries.
  107.     Examples are /usr/lib/libc.so.* and /usr/kvm/libkvm.so.* on
  108.     SunOS-based machines.  Although we have only received reports of
  109.     SunOS-based machines being altered, the techniques used by intruders are
  110.     applicable to other systems that use shared object libraries.  These
  111.     libraries are being modified so that the presence of certain directories
  112.     and processes cannot be detected with vendor-provided programs or public
  113.     domain programs built to use shared object libraries.  This means that ANY
  114.     program using these shared libraries will act in the manner described by
  115.     the intruder without the intruder necessarily having to modify the program
  116.     itself.
  117.  
  118.     The Trojan horse daemons previously described typically become "invisible"
  119.     to programs such as ps once the kvm shared object library has been
  120.     modified.  Similarly, the directories used by intruders for building
  121.     these daemons are "invisible" once the libc shared object library
  122.     has been modified.  Again, do not rely on checksums using sum(1) or time
  123.     stamps to detect altered files.  Use a known clean version of cmp(1) or a
  124.     strong checksum technique such as MD5 to verify your files against the
  125.     appropriate distribution.
  126.  
  127. ---------------------------------------------------------------------------
  128.  
  129. If you believe that your system has been compromised, contact the CERT
  130. Coordination Center or your representative in the Forum of Incident
  131. Response and Security Teams (FIRST). 
  132.  
  133. If you wish to send sensitive incident or vulnerability information to
  134. CERT staff by electronic mail, we strongly advise that the e-mail be
  135. encrypted.  The CERT Coordination Center can support a shared DES key, PGP
  136. (public key available via anonymous FTP on info.cert.org), or PEM (contact
  137. CERT staff for details). 
  138.  
  139. Internet e-mail: cert@cert.org
  140. Telephone: +1 412-268-7090 (24-hour hotline)
  141.            CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
  142.            and are on call for emergencies during other hours.
  143. Fax: +1 412-268-6989
  144.  
  145. Postal address:  CERT Coordination Center
  146.                  Software Engineering Institute
  147.                  Carnegie Mellon University
  148.                  Pittsburgh, PA 15213-3890
  149.                  USA
  150.  
  151. CERT advisories and bulletins are posted on the USENET news group
  152. comp.security.announce. If you would like to have future advisories and
  153. bulletins mailed to you or to a mail exploder at your site, please send
  154. mail to cert-advisory-request@cert.org. 
  155.  
  156. Past CERT publications, information about FIRST representatives,
  157. and other information related to computer security are available by
  158. anonymous FTP from info.cert.org. 
  159.  
  160. ---------------------------------------------------------------------------
  161.  
  162. Copyright 1995 Carnegie Mellon University
  163. This material may be reproduced and distributed without permission
  164. provided it is used for noncommercial purposes and the copyright statement
  165. is included. 
  166.  
  167. CERT is a service mark of Carnegie Mellon University.
  168.  
  169.  
  170.